It occurred to me that this PR might have objectionably large memory requirements (similar to #1402) so I did some memory profiling and found that a call to get_irradiance() with inputs of length 10000 increased peak memory usage from ~50 MB on main to ~900 MB on commit 0d80d7d. I was able to get that peak down to ~470 MB with some strategic usage of del in 9bf9360:

The memory load is still larger than I'd like, but with that reduction I'd say it's an acceptable price to pay for the runtime improvement. I'm curious what others think.

1 year of 1 minute data is about half a million points. If memory usage scales linearly with that dimension, then I think some users will run into a problem.

Good point. Well, taking full advantage of numpy's out parameter (and unfortunately making the code substantially less readable) gets the calculation down to 207 MB peak usage for the 10000 points case. For 525600 points, peak usage is 11 GB. I think there is not much room for additional improvement in _vf_ground_sky_2d beyond what is implemented in 6f490ea. Maybe it's worth adding a vectorize=True kwarg that the user can set to False if they want to use the old loopy approach to prevent memory blowup?

Updated plot:

If we add a vectorize kwarg I'd default to False.

I'm not a numpy expert, especially in regards to performance, but this looks reasonable to me. Perhaps a numba element by element calculation would combine readability, performance, and reasonable memory usage. Perhaps.

Ok, I added a new vectorize=False kwarg to infinite sheds. I think I'm satisfied with this PR now.

Here's an asv runtime comparison:

$ asv run --python=same -e -b InfiniteSheds
· Discovering benchmarks
· Running 4 total benchmarks (1 commits * 1 environments * 4 benchmarks)
[  0.00%] ·· Benchmarking existing-pyc__users_kanderso_software_anaconda3_envs_pvlib-dev_python.exe
[ 12.50%] ··· Running (infinite_sheds.InfiniteSheds.time_get_irradiance_fixed--)....
[ 62.50%] ··· infinite_sheds.InfiniteSheds.time_get_irradiance_fixed                                                 ok
[ 62.50%] ··· =========== ============
               vectorize
              ----------- ------------
                  True      79.4±1ms
                 False     78.2±0.4ms
              =========== ============

[ 75.00%] ··· infinite_sheds.InfiniteSheds.time_get_irradiance_poa_fixed                                             ok
[ 75.00%] ··· =========== ============
               vectorize
              ----------- ------------
                  True     39.1±0.5ms
                 False     38.5±0.7ms
              =========== ============

[ 87.50%] ··· infinite_sheds.InfiniteSheds.time_get_irradiance_poa_tracking                                          ok
[ 87.50%] ··· =========== =========
               vectorize
              ----------- ---------
                  True     174±2ms
                 False     272±5ms
              =========== =========

[100.00%] ··· infinite_sheds.InfiniteSheds.time_get_irradiance_tracking                                              ok
[100.00%] ··· =========== ==========
               vectorize
              ----------- ----------
                  True     365±20ms
                 False     552±7ms
              =========== ==========

This PR is ready for another look if @cwhanse or @wholmgren (or anyone else, of course) is interested. The new vectorized calculation path is now gated behind an optional vectorize parameter with the original low-memory serial calculation path still the default.